Trino 的資料來源

了解了 Trino 的組成架構後，也必須知曉 Trino 對資料來源的與存取與管理做了什麼樣的設計，畢竟這對一個好的查詢引擎來說至關重要：

1. 目錄 (Catalog)
   • 是一個邏輯上的分組，用來管理某個 Connector 的相關資料
   • 可以想像成一個資料夾，裡面放了很多資料庫和表格
   • 每個 Connector 都會對應到一個目錄，方便管理和存取不同的資料來源
2. 基模 (Schema)
   • 是目錄裡面的 Namespace，用來存放表格和其他基模
   • 可以想像成資料夾裡的子資料夾，裡面放了許多表格
   • 類似於關聯式資料庫 (RDBMS) 中的資料庫
3. 表格 (Table)
   • 是基模裡面結構化的 dataset，由行 (rows) 和列 (columns) 組成

Trino vs. Hive

說了這麼多，Trino 的優勢可能還不夠具體。因此，在最後我們將透過 Trino 與 Hive 的比較，讓大家更清楚了解 Trino 的優點。

事實上，Trino 最初就是為了解決 Hive 在 HDFS 上分析效能不佳的問題而誕生的。因此，將 Trino 與 Hive 進行比較，最能突顯資料湖倉的優勢。我們將從以下幾個面向來進行比較：

1. 執行查詢的模式
2. 查詢的效能 (performance) 與延遲 (latency)
3. 儲存模式 (*因 Trino 是查詢引擎所以沒有儲存資料的概念，故這邊可理解為可讀取並查詢的資料源)
4. 處理 *基模 (Schema) 的模式
5. 適合的使用場景

*基模 (Schema)
真不喜歡這類很常被複用的同字異義技術名詞，這邊的基模(Schema)與前一節Trino資料來源所述不同；
這邊指的是Table schema，也就是表格的資料欄位、格式與限制等定義

透過上表 Hive 與 Trino 的比較我們可以知道幾點：

1. 相較於適用單一資料庫的倉儲查詢引擎，Trino 在查詢資料來源上更有彈性，可以連接更多 HDFS 以外的資料源，如 AWS S3
2. 相較於 Hive 的 *MapReduce 批次作業，Trino 的 in-memory 查詢及分散式特性使互動式的分析查詢的效能更好、延遲更低
3. *兩者都是使用 Schema-on-read 模式，不需於寫入時定義資料格式，因此較有利於 Object storage 形式的儲存
4. 兩者皆使用 Hive Metadata 來管理資料版本以及優化查詢效能

*MapReduce
MapReduce 是 Hadoop 的一個計算框架，適合用來處理大量資料；它將任務分成兩階段：
1.Map：將資料拆成小塊，並對每一塊進行處理。
2.Reduce：將 Map 階段的結果合併，得到最終的答案。

*Schema 模式
Hive算是特例，一般傳統倉儲常用的是Schema-on-write 可就沒有這個好處了。

這些特性對分析架構 (OLAP) 帶來幾個好處：

1. 不須再為了多資料來源開發許多 ETL 做資料搬運，透過單一查詢引擎即可滿足多來源的分析需求
2. 使用 Schema-on-read 讓寫入更加彈性，有利於半結構化 / 非結構化資料的儲存與分析，讀取則靠 Metadata 優化
3. 倚靠 Metadata layer 幫助，優化低儲存成本的 Object storage (如 AWS S3)、開源 HDFS 的讀取效能，免除供應商的箝制
4. 以 in-memory 的高速查詢取代適合批次作業的 MapReduce，對想要立即知道臨時分析結果的分析人員可說是一大福音

明日預告

與其紙上談兵，不如動手實作。
明日起的系列文《Trino 地端架設與調參 (一)》，將從零開始帶你在地端完成 Trino Cluster 的架設，並逐步介紹關鍵的設定與調校方法。

Know me more

My Linkedin: https://www.linkedin.com/in/benny0624/
My Medium: https://hndsmhsu.medium.com/